Designers in many disciplines, from architects to electrical engineers, have developed patterns that describe solutions to commonly encountered problems. For example, there is a large body of pattern literature for constructing residences, covering almost all aspects of building a home—from framing, plumbing, to electrical wiring. This pattern literature has been in existence for years.
Patterns have taken root in software only recently. “Design Pattern Elements of Reusable Object-Oriented Software,” by Gamma, et al., is the first landmark work that addresses patterns for software. It was not published until 1995. This work is commonly referred to as the GANGOF4BOOK.
Design patterns, as the term is used herein, describe objected-oriented programming solutions to commonly encountered problems and issues. Design patterns are important for improving the quality of software because design patterns provide a framework for solving fundamental challenges in software system development. Design patterns describe solutions developed by the icons of software development, communicate established solutions to developers at large, and avoid development traps and pitfalls that are usually learned by experience. Objected-oriented programming is described in Appendix A.
An example of a design pattern is an iterator. The iterator design pattern addresses the commonly encountered problem of sequentially accessing each number of a collection of objects, such as an array of objects. The iterator design pattern describes a solution for sequentially traversing objects in an underlying data structure without having to be concerned with the particular data structure. Specifically, the iterator design pattern specifies that an iterator object maintains a current position in the data structure. The iterator object should also have a method that (1) returns a reference to the object in the next position, and (2) sets the current position to the next position, if any.
Another commonly encountered problem is providing concurrent access to a shared resource. Shared resources include, but are not limited to, shared memory, data structures, and peripheral devices. Solutions for concurrently accessing a shared resource involve explicit cooperation between the various executing entities (e.g. processes, threads) accessing the shared resource. These solutions typically use various locking mechanisms, such as locks, monitors, and mutexes, to coordinate access to the shared resource.
Developing software to implement explicit cooperation between processes and threads can be very cumbersome and tedious. Generally, it is substantially easier to develop software for accessing resources that are not shared by processes or threads.
A methodology that allows a process or thread to access a shared resource, as if that resource were not shared, would relieve a developer of the complicated work of developing software that must provide explicit cooperation between processes and threads for accessing a shared resource. Currently, there is no design pattern that describes such a solution. Clearly, such a design pattern is desirable.